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Fast Restoration 



Background of the Invention 

1 5 The present invention relates to the field of telecommunications and more 
porticulorly to a method for re-configuring o network element of o 
transmission network to restore traffic ofter occurrence of a failure. 

Background of the Invention 

20 

A Digital Cross Connect (DXC) must react in some scenarios as fast as 
possible. For instance in the case of a fiber cut, traffic from this fiber must be 
restored very quickly ("Restoration"). In meshed networks (e.g. SDH or SONET 
networks) the capability of fast restoration is very important. The required 
25 configuration changes shell thus be occelerated. 

DXC systems typlcolly use a layered 5W architecture, where each layer checks, 
processes, ond stores configuration requests before these requests are 
forworded to the next lower loyer. Acceleration of this request processing is 
30 especially needed in meshed SDH networks 

There are solutions to outomate the traffic rerouting, which are based on 
predefined restorotion scenarios. These solutions, however, need a lot of 
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implementation effort and consume more resources in terms of troffic 
capacity. 

Summary of the Invention 

5 

The present Invention proposes a two-phase opproach that accelerates the 
normal hardware re-configuration in o network element. 

Each configuration request is divided into two phases: At first the "Fetch- 
10 Ahead" phase and then the "Consolidation". During Fetch-Ahead no 

consistency checks are performed, the changes are not mode persistent in the 
database and only the absolutely necessory changes are done. After Fetch- 
Ahead these changes are temporarily valid in all SW layers. During 
Consolidation all the remaining things^ which are skipped during Fetch- 
1 5 Ahead, are done. 

This accelerates re-configuration, especially in restoration scenarios. If two 
requests follow each other directly, the second request is delayed until the 
consolidation of the first one has been finished. 

20 

Detailed Description off the Invention 

In the following, preferred embodiments of the invention will be described in 
more details. 

25 
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CHAPTER 1: 



Introduction 



1.1 



Purpose of the Document 



The purpose of this document is: ^ 
m To provide a detailed external description (behavior) of this feature as a whole. ^ 

■ Tb provide an overview of the general and specific requirements for the feature. ^ 

■ To specify the impact of this feature as it is implemented across the various segments. ^ 

m To describe new or changed interfaces between all affected segments of the DXC soft- ^ 
ware. 

■ To identify the overall test strategy to be applied for the feature. ^ 

m To identify all assumptions, limitations, and risks associated with the proposed design. ^ 

This document should be used as the reference document for more detailed design of the af- ® 
fectcd segments. 



1.2 Scope of the Document 

This document describes the behavior and implementation of the Fast Restoration feature as 
a whole. The feature implementation is discussed, including — but not limited to — its general 
capabilities, the external behavior as represented by the user interface, network interfaces, 
hardware interfaces, services, and limitations. Also described is the impact of the feature on 
existing segments with emphasis on any changes in the current behavior or functionality. Fast 
Restoration will be first implemented in 1674 J^amdaGate 1.3. It is planned to support also 
for R2.3 Fast Restoration. 



1.3 Organization of the Document 

This section gives a brief overview of how this document is organized. It is important to under- 
stand the organization of the document in order to follow the contents in an easy way. 

• Chapter 1 provides an introduction to the document by describing the purpose, scope ^ ^ 
and organization of the document. 

■ Chapter 2 provides a description of the feature's external behavior in such away that it 
is clear 10 any customer, test engineer or design engineer what capability is provided 
and how it works. This can be illustrated by well— chosen scenarios. The chapter de- 
scribes also all requirements. 

■ Chapter 3 describes the changes to segments required for the implementation of the 
Fast Restoration feature. 

14 

■ Chapter 4 identifies the impact on existing or new interfaces. 



i 
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■ Chapter 5 provides basic scenarios ^ 

■ Chapter 6 identifies all assumptions on which the design is based. In addition, any ii* 
mitations imposed by the design are clearly noted. Finally, any risks or undesirable side 
affects which can be foreseen are described. 

■ 7*he Glossary and List of Abbreviations and Acronyms sections define the terms and 
abbreviations used in this Concept Paper. 

■ Bibliography provides a Ust of documents referred to within this Concept Paper. ^® 

■ History lists the Change History of the Concept Paper and the Planned Changes for the ^ ^ 
next edition of the Concept Paper. 



1 
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CHAPTER 2: Feature Description 



This chapter provides the user with a complete understanding about how the Fast Restoration 
feature works from an external point of view. 



2.1 Background 

Flexibility, efficiency and restoration make meshed networks getting more and more interesting 
as alternative to ring network structures. Today the decisive disadvantage of meshed networks 
is the long restoration time. Lab tests have shown that in a quite simple network topology with 
3 nodes the restoration of 8 AU4— 4c takes about 10 seconds. This time is not acceptable for 
the customer since other vendors offer restoration within 200m$ in such simple networks. 




Figure 1: Actual Situation 

A detailed analysis, sec also Figure 1, has shown that the main time slice is consumed in the 
NE for the implementation of the new paths* A less significant but nevertheless not negligible 
delay is caused by alarm detection and propagation. Further delays are intentionally imple- 
mented in MIB/NP to cumulate alarms before reporting / reacting. 

It has to be mentioned that the current SW architecture was implemented with an emphasis 
on a secure provisioning mechanism and naturally this security is paid with additional process* 
ing time. 

To be competitive a restoration time of 2 seconds and less has to be achieved when restoring 
64 single VC4. The proposed solution tries to keep the benefits of the current impJemcntation 
and the general architecture of the DXC while accelerating the path implementation. 

2.2 General Description 

l\vo phases have to be distinguished for the improvements: 
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• alarm detection, alarm propagation and path rerouting 

• path implementation 

The first phase needs minor architectural changes and optimizes the actual implementation 
and each involved component. At first the alarm detection time at SC level is reduced for impor- 
tant alarms (LOS, LOF, MS— AlS). These alarms are not delayed with a hold off time in MIB 
or NP but they arc immediately processed. Also secondary path alarms, mainly VC— AIS or 
VC— SSF are polled with a higher frequency (but not as fast as LOS, MS— AIS). As a conse- 
quence the hold off times in M IB and NP can be reduced because the alarms from ail I/O subsys- 
tems in the DXC, respective all network elements in the network, should be received in a small- 
er time window. 

Receiving a primary alarm NP will analyze which VC4 paths are affected and then it starts 
immediately the rerouting. 

The major objective for path implementation is performance. Not less important is that the 
system reliability is not affected. Tb meet these opposed requirements it is necessary to split 
the processing in the NE into two steps: 

• The first step (fetch— ahead) is designed to minimize processing time and to implement the 
new paths as early as possible. This step provides reduced security against process restarts 
and ignores all activities which are not absolutely necessary for path restoration. 

• The following second step (consolidation) is executed in the traditional way (slower & sc- 
cure). It is very similar to the actual implementation. 

In nearly all cases the fetch— ahead will be successfully executed and only if an exceptional 
event happens^ e.g. a process crashes^ it may fail. Such an exception will only affect the path 
restoration time since the following slower consolidation step will anyway create the requested 
new paths. 

An overview scenario is given in Figure 2. The MIB expands the compact message format of 
the restoration request, scans the request and filters all connection relevant information. The 
filtered information is directly translated into the VHM message set and sent to VHM (Msg 
2). 
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Figure 2: Overall Scenario Path set up 

As today VHM/FWA broadca5;ts the message 'startlloIdOff ' to all I/O shelves so that no con- 
nection failed alarm nor consequent actions nor matrix EPS is executed while the connections 
are instable. Then VHM disables the persistency management, e.g. all the following modifica- 
tions are not written to disk or copied to the redundant NAU but they remain only in memory. 
The information received by VHM is already filtered for connection relevant information. As 
a consequence VHM activity is automatically focused on creating the new paths. Further im- 
provements, e.g. special processing for the fetch— ahead, or the collection of concatenation 
information per shelf is implemented to reduce processing and communication limes. When 
all configuration is calculated VHM sends the configuration messages to FWA. Also these mes- 
sages contain the 'fetch— ahead' indication. 

The center stage configuration is sent as a normal connection request which contains the 
'fetch- ahead' indication. The configuration messages are duplicated by VHM to both center 
stage matrix copies. 
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For the SC configuration FWA receives only a single message per J/O shelf which contains 
the concatenation and endstage connection information. This information is sent as a single 
container message to the active SC and implicitly includes 'StartUpdProv' and 'UpdProv'. 

SC analyses the database changes and limits the calculation of register maps to connection 
relevant information. This will partly be achieved because FWA sends a reduced number of 
blocks to the SC. Nevertheless SC executes an optimized ASIC provisioning because it knows 
that this fetch— ahead pass is limited to the creation of new connections. 

As a result the paths are very early restored. But the fetch— ahead leads to an inconsistent con- 
figuration which will not survive any process restart or EPS. The configuration is inconsistent 
with respect to PM, path monitoring, internal supervision configuration. Due to the inconsisten- 
cy the lO shelf SC will not resume the suspended tasks — this is done when the consolidation 
is received. 

When VJHM and FWA have finished their communication VHM sends the fetch— ahead re- 
sponse to the MIB and then MIB starts processing the original restoration request in the normal 
way (consolidation): It creates and updates all MOs, connections, etc. and makes them persis- 
tent. At the end the consolidation request is sent to VHM. 

Even fur the consolidation the startHoldOff has to be broadcasted to all I/O shelves. This is *^ 
necessary for certain SC restart scenarios. 

Also VHM manages this request as today: all connections, monitors, etc. are configured and 
then persistency management is enabled again. When all data is persistent MIB gets the ac- 
knowledge for the request. VHM shall reuse results from the fetch— ahead step, mainly the 
matrix routing must be the same in order to avoid hits on already restored traffic. 

During consolidation FWAmaps all configuration blocks and sends them to the SC. Someinfor- 
mation from the fetch— ahead will be simply re— written and there is no need to optimize the 
mapping. 

The SC processes the consolidation request and afterwards all tasks are resumed. 



2.2.1 Overlapping Restoration Requests 

This chapter has still to be completed but for the implementation of the first iteration it should 
be considered that the system has to managed a second restoration requests before the consoli- 
dation of the first request is completed. This is not planned for the moment. 
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CHAPTER 3: Requirements 



The reeiiUrements for restoration are described with Figure 3. In case of a fiber cut for the nor- 
mal tralYic between LGl and LG2 the traffic has to be restored within 2000ms. 



o 



64 VC4 /<^r'"i>^ 




fiber cut 



measurement device 



i,Gl,2,3 are different NEs 



LSG5d traffic restored in 2000ms 



figure 3: Reference Testenvironment 



The overall requirement of 2()00ms protection time is detained with Figure 4. It defines the 
maximal times the different processing steps may need. 
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Figure 4: Target scenario with 2000ms restoration time (Fetch ahead) 

• FWA shall receive the primary fault at T.i = 150ms (F4 filter value is 100ms) 
NP shall receive the prhnary fault at T2— 160ms 

• At T3s^ 800ms MIB shall receive the restoration request. 

100ms later, at T4=890ms VHM receives the filtered Fetch-^ahead configuration 

I/O respective matrix subsystems receive the last configuration message at 
T6=1440ms. 



• ASIC configuration is finished at T7=2040ras. 
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CHAPTER 4: Architecture and High -Level Design 



Tliis chapter describes the architectural impacts of the segments. Figure 5 gives an overview 
about the processes involved in restoration (with tbe focus on fetch— ahead) and how they inter- 
work. In the following subchapters they are described in more detail. 
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Figure 5: Fast Restoration Overview 
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4.1 MIB 

Three main changes are necessary in the MIB: the alarm handling, the two phase approach 
with fetch— ahead and consolidation and improvements during consolidation. 



4.1.1 Alarm Handling 

At the moment, received alarm notifications from VllM are stored in MIB until a hold— off ^® 
time of 300 msec expires. This is no longer feasible for fast restoration. It must be changed 
in the following way: 

■ Incoming alarms are collected in a ChangesCollection Import 

m Check the ProhableCause of the alarm ^® 

■ If the ProbableCause indicates, that it is a primary alarm (LOS, LOF, MS— AIS), this atami ®® 
and all alarms already collected in the ChangesColleciionRepon arc sent to NP at once 

■ For all other alarms a configurable hold- off timer (range: 0.-300 msec) is started (if it is the ®° 
first alarm in Changt^sCollectionBeport) 

m On expiration of this hold— off timer or if a primary aiami arrives (see above) all collected 
alarms are sent to NP 

A further needed improvement is to send the alarms to NP before they arc stored in Persistency. ®^ 
At the moment the alarms are sent in the committed phase of a transaction. In future they must 
be sent in the prepartToCommit phase. This ensures that the writing to Persistency and especial- 
ly the sending and writing to the redundant AIJ is done after sending the message. 

4.1.2 Two Phase Approach 

A new mechanism is needed for the fetch— ahead processing, i.e. the mapping of the incoming 
request to a VHM request and nothing else, especially no storing to Persistency. 

in addition it must be ensured, that after every fetch— ahead processing the VhiSendControUer ^ 
sends at once the resulting message to VHM and that an eventually incoming further request 
(restoration or non— restoration) is not handled until the consolidation phase is finished. 

To avoid, that the processing of the restoration request is delayed in situations where a lot of 
requests from RM or a lot of alarm events from VHM are queued in MIB, the handling of 
the rcque.stR coming from NP must be prioritized (bit 4.2). 

66 

The restoration request must be tittered for connection relevant delta to be mapped and sent 
directly to VHM. These data are: 

■ connections (both for creating/activating and for deleting/deactivating requests). Note that 
commands e.g. force switch in case of an SNCP are ignored in VHM during fetch-ahead 
(but are needed during consolidation e.g. because of soft rerouting) 

68 

■ concatenation levels 

In fact, MJB sends the connection requests towards VHM and VHM is responsible to pro- ®^ 
vide the correct concatenation level of the TPs to be connected, i.e. MIB docs not send 
an explicit concatenation request. 

Before starting the consolidation, MIB should wait some time in order to give VHM, FWA 
and IntComm processes access to the system resources, especially the CPU computing time. 
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Therefore for the fetch- ahead communication an own socket is used between MIB and VHM 
(this socket is prioritized in VHM). When VHI has sent the fetch-ahead request to VHM. 
it waits until VHM sends the fetch -ahead response on this socket (icr Figure 5). This response 
indicates that all lower level processes have completed their fetch- ahead processing. 
The waiting on this special socket should be implemented by using the progrexslnstance method 
of SocketComra. This ensures that no other requests are handled. Becaixsc progresslnstunce 
returns not only when a user message arrives but also on arriving of a aUve message (even it 
this alive message is received on another socket!), on every return MIB has to check whether 
the response has arrived from VHM. Then the consolidation can be started at once. 
To handle errors, where VHM never sends the response, MIB needs a time-out. Unfortunately 
it is not possible to do a progress Instance with time-out. Therefore the alive mechanism is used 
instead- The fetch -ahead .socket is instantiated with a keep -alive of 30 seconds (a long time- 
out but it is only needed in a very improbable error case). This ensures that at least eveiy 30 
seconds the progrcsslmtance returns. Because it returns too when an alive message is received 
on another socket, the time the request was sent, must be kept in MlB (not per.sistent). The 
waiting for VHM is stopped if more than 10 seconds have been passed. Even in this error case, 
the consoUdation is started (including the normal error bandUng, if needed). 

73 

In case of a VHM process restart the fetch-ahead socket is closed. This is a trigger lor MIB 
to start the consolidation at once. Closing the fetch - ahead socket means that the method comj- 
Brohen is called. Furthermore the progresslnstance method return.s at once with return code 
false. 

Special care has to be taken for cases where the consolidation phase aborts for any reason (e.g. 
MIB process restart or if the restoration request is rejected by MIB during the checks in the 
consolidation phase). Because no storing to Per.sistency is done in the fetch- ahead phase (even 
not the request itself), in case of a MIB process restart, the restoration request is totally los 
in MIB The NP detects this MIB restart and starts at once a rerouting over other NEs. But 
because the fetch-ahead request is already sent to VHM and therefore also valid in the HW 
a mechanism is needed to trigger a fall back to the former state: As .soon VHM detect^^^^ 
the fetch-ahead connection to MIB is broken, it has to ree.stabhsh its state before the fetch- 
ahead request (by a simple process restart or an explicit transaction rollback). Also the 
and theCCUmustfallbacktotheconfiguration before the fetch-ahead(seebelowfordetail.s).^^ 

if MIB rejects a restoration request, the VHM (and again SC and CCU) must also reestablish 
their pre-fetch-ahead state. MIB can trigger this by a simple close and restart of thejetch- 
ahead connection to VHM. This is interpreted in VHM like a MIB process restart and handled 
accordingly. 

Note that as long as NP does not distinguish between Restoration, Soft-Rerouting and normal 
connection build up, every (restoration-) request is handled in two phases, ^-^^^JoK^X more 
time is needed between request from NP and response to it (after consolidation phase is fin- 
ished). 

4.1.3 Improvements during Consolidation 

Though the fetch-ahead ensures, that the disturbed traffic is very fast restored the consolida- 
tion hself m^^^^ be improved: Find the weak points e.g. with the tool Quantify and solve the 
already known problems (ox SLSks25202). 



(&r: ♦49 711 821 44599 



ALCATEL IPO 



12/'ll/'02 18:43 



S.: 19^62 



^3 
▼ 



A L C A T C I. 



4.2 



MIB Framework 



To ensure that a request from NP is always handled with the highest priority (consider a situation 
where a lot of requests from RM or a lot of alarm events from VHM are queued in MIB to 
be processed), the priority of the Session Request Handlers, especially of the user NP, must 
be configurable (sec following figure and description). 
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1 : jncomingLoginRequest 



2: checkSossionExIst 



3: checkUserPrlvileges 



4: getUserPriority 

■ _n 



5: triggerCreate 



6: newSRH(sessionldp priority) 



i?: create(priority) 



Figure 6: Prioritization of SRH 

When a user tries to log— in, the ACM has to check the authorization and privileges of this 
user- These privileges must also determine a priority class. The value itself can be determined 
per configuration file like it is already done for the type SRH. The priority (or the priority class) 
then can be passed to the MRH which creates the SRH NPOS (and implicitly the corresponding 
phase) with the higher priority. 



do 



4.3 VHM 

lb implement the two pass approach, VHM has to do: 

43.1 Handling and fonvarding of fetch— ahead indication 

Anew message attribute has to be defined in the VHM message set, indicating the fetch- ahead ®^ 
(to indicate the consolidation messages, the Restoration Container message is used). This 
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fetch— ahead request message is sent from MIB via a special socket connection with a higher 
priority than the normal connections to ensure the precedence of the fetch— ahead. 

When receiving the fetch— ahead request, VHM has to change its internal state to indicate 
that a special handling (see below) is needed* Beside of this, VHM sends at once (as usual) 
the RestorationStart message to FWA, adapts the concatenation levels of the involved TPs (c^ 
43.4) and performs the usual connection handUng. 

At the end of the fetch— ahead processing, VHM sends the new connectivity messages together 
with the concatenation information in a single message per shelf (iry 4.3.5) with a fetch— ahead 
indication to FWA. 



4.3.2 Inhibit Persistency during fetch— aiiead 

lb avoid the time consuming writing to Persistency during fetch— ahead, VHM disables Persis- 
tency. This can be done centraUzed in the VHM platform: The during fetch— ahead changed 
objects register themselves as usual in ObjCommDB resp» PersRecHdlr. But at the end of the 
request processing they are not written to Persistency but are still kept registered. This ensures, 
that they will be written after the following consolidation processing, though they may not 
(again) change their attributes during consolidation (and therefore usually will not register 
themselves). 

Open issue: PersRecHdlr receives and keeps only pointers to the data to be stored. Therefore 
tlie databuffers behind these pointers must not be deleted until consolidation. 

In addition the handling of empty transactions should be improved: Avoid the starting of a 
Persistency transaction if no data has to be stored, eg when receiving an intermediate response 
from FW/FWA (j^ SLSks25208). 



4.3.3 Limited configuration in fetch — ahead 

It has to be ensured that only the messages concerning connections and concatenation are sent 
to F WA, e.g. no PM configuration (default when changing the concatenation level), no TP con- 
figuration, etc. 

Normally every changed object registers itself at VHM Flow Control and at the end of the re- 
quest processing these registered objects are called back to enable them to send their complete 
configuration to FWA (including the changed attributes). During fetch -ahead all registered 
objects must be kept registered. In the following consolidation they are called back and they 
send their then actual complete configuration to FWA (including further during consolidation 
changed attributes). 



4«3.4 Implicit concatenation requests in fetch'-ahead 

If for a restoration request the concatenation level of a TP has to be changed, VHM has to 
detect this autonomously in the connection request and must change it. During fetch— ahead, 
MIB performs a simple mapping without checking the actual states of the involved TPs. There- 
fore no explicit concatenation request is sent to VHM. 



4.3.5 



Collect and send concatenation information separately 



I 



If the concatenation level changes, VHM has to create rcsp. delete the corresponding objects. 
This must be done even during fetch— ahead to allow the creation of new cross connections 
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via these concatenated TPs (e.g. to be used in the matrix routing algorithm). Usually these 
new objects send their (default) configuration to FWA, including a lot of information not need- 
ed during fetch— ahead. 

lb avoid these configuration messages, which must be transmitted to FWA, and also to simplify 
and accelerate the job of FWA, the concatenation information must be stored separately per 
I/O shelf. This information then can be sent in a new (to be defined) submessage to FWA> 
together with the connection information. I.e. only one message per shelf is sent (saves commu- 
nication time) and it is addressed to the active SC. 

It is a good idea, to store the additional concatenation information at the HCSMX board object 
because then in the flow control send pass only this board needs to be called back. All other 
link and I/O boards, as well as the TPs on them, have nothing to send resp. must not send any- 
thing. 

Note that the concatenation information is only needed in the I/O shelves. For the CS shelves 
the connection information is sufficient. 



4.3.6 Special socket fur fetch*- ahead requests from MIB 

Tt> prioritize the fetch— ahead request over other actual queued requests (from MIB as well 
as from FWA, especially PM reports) and also to enable MIB suspending itself ((nr- 4.1), a new 
socket has to be defined. This new socket is exclusively used for fetch -ahead communication 
between MIB and VHM: MIB sends the restoration request, VHM sends a response (after 
all messages to FWA are sent and an additional, configurable time— out is expired, %r 4.3.7). 
Its priority is set to /i/jg/i, i.e. the same priority as e.g. the configuration socket to FWA. 

4.3.7 Delay fetch — ahead response to MIB 

To give the MIB a trigger, when it can start the consolidation (cy Figure 5, 4.1), the fetch- 
ahead response to the MIB request is delayed until the complete fetch— ahead configuration 
(for all involved I/O and CS shelves) is sent to FWA. Because FWA then needs some time to 
map these requests and to send them further on towards SCs resp. CCUs (via IntComm), VHM 
calls the msecSleep method (fr^ SFXJM/basicfrw/BasiCwS/UNlXIF/nisecSlecp.h) after having 
sent the last request to FWA. The value of this sleep must be configurable. Its range should 
be from 0 to 500 msec with a default of 50 msec. 

When this timer expires, VHM sends the response to MIB which starts at once the consolida- 
tion. 

Note: The following discu.sscd alternative to the delay timer is not feasible: For every fetch— 
ahead request from VHM, FWA sends a notification event back to VHM after it has mapped 
and sent this request further on to the SC rcsp. CCU (in addition to the normal response, which 
is sent after FWA has received the response from SC/CCU). VHM collects all these notification 
events and as soon as for every involved shelf such.a notification has been received, the fetch- 
ahead response can be sent to MIB. 

This alternative has the big disadvantage (beside of the bigger implementation effort), that 
FWA has to do more work during fetch— ahead. Sending a notification event needs an addition- 
al phase in FWA and this will delay the execution of the following fetch— ahead requests (for 
further shelves). 
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4.3.8 Make all changes persistent in consolidation pass 

Because in the fetch— ahead pass no storing to persistency is done, all changed objects must 
be written in the consolidation pass, together with the additional objects, changed during con- 
soUdation. Special care has to be taken for data of the MCL category, because here only point- 
ers to data buffers are registered to be stored. It has to be ensured that after the fetch— ahead 
transaction, these pointers, as well as the related data buffers, are still valid and can be stored 
in the consolidation pass. 



4.3.9 Repeat fetch— ahead configuration in consolidation pass 

All the configuration and connection requests during fetch— ahead are sent to the active SC 
resp. the two active CCUs (of copy A and copy B) only. Therefore they must be repeated during 
consolidation. For new or changed objects lUcc TPs this can be easily achieved by keeping them 
registered at the VHM flow control. Then they arc called back during consolidation and send 
their now actual configuration (including further changes made during consolidation) towards 
FWA. 

For connections it is a little bit more complex: The connection requests which are repeated 
from Ml 8 during consolidation arc recognized as abready valid. Therefore nothing has to be 
done in VHM and nothing would be sent to FWA. This ensures that no new routes through 
the matrix are calculated for the connection requests, repeated in the consolidation. 

To ensure that the connection requests are repealed, a total connection reload is triggered, 
i.e. to all matrix boards in CS and ES the complete list of their active connections are sent. 



4.3.10 Delay rearrangement after consolidation 

If during a fetch— ahead, the matrix SW recognizes a need for a rearrangement, this part of 
the connection request is ignored. But all the other possible connection requests are handled 
as usual in the fetch— ahead. During the following consolidation phase, the same happens: the 
possible connections are recognized as already present, those leading to rearrangement are 
negative responded to MTB and the consolidation phase is finished. 

Having received a negative response with rearrangement indication, M.TB resends these con- 
nection requests but now outside of restoration- Now they are handled in VHM as usual^ i.e. 
the rearrangement is performed. 



4.3.11 Maintenance processes 

It is a useless relict from old releases that in 1674LG VHM maintenance processes like CCX, ^ 
AM and UAEM are running though they arc no longer involved in the normal request process- 
ing. Though the additional notifications, the VH M process sends to these processes need nearly 
no time, the problem is that they need system resources (e.g. CPU time). Therefore they must 
not be started any more (simply change the SSU startfile). 



4.3.12 Improve alarm processing 

At the moment an incoming alarm is processed by the responsible object(s). Then the persistent 
data of these objects arc handed over to Persistency. Then the alarm notification is forwarded 
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to MIB and at last Persistency writes these data onto the disk. Improve this handling by sending 
the alarm notification(s) to MIB before the persistent data are handed over to Persistency. 



4.3.13 Improve restoration request processing 

The two pass approach with fetch— ahead ensures that the connections are very fast up. But 
beside of this new mechanism it is useful to check whether further improvements are possible, 
e.g. avoid unnecessary checks, object creations, comparisons, whatever else. Especially the 
parts which arc executed during fetch— ahead (concatenation, cross connection handling, ma- 
trix routing) etc.) must be considered. Tools like Quantify can be used to identify the time con- 
suming parts. 



4.3.14 Precedence of configuration 

The SCs and CCUs are separated machines and executes the requests in parallel. Therefore ^ 
the send ordering of the requests should be in a way: the slowest entity first. At the moment 
the slowest entity in a Square configuration is the Main Shelf SC, in a CLOS configuration 
it is expected that the I/O shelves are slower than the CS CCUs (has to be verified). 

4.3.15 Improve message preparation time 

Measurements showed, that the time needed to build up a message to matrix boards (CXlOOO ^ 
as well as HCSMX) is much longer than to I/O boards (though the total amount of data is equal). 
This should be examined and improved. 

The configuration for both matrix copies is equal. Therefore the message to the second copy ^ 
should be simply copied from the first request and not set up from scratch. 



4.3.16 CXlOOO board configuration 

Up to now connections are brought onto the CS matrbc boards by triggering a total configuration ^ 
reload. But during fetch— ahead the FW on the CS CCU docs not check its database whether 
the requested connection is already present. This implies, that all requested connections are 
brought onto the HW. And because this needs a lot of time, it must be avoided. This is why 
during fetch— ahead only the new connections have to be sent (note that VHM needs a little 
more time to setup a list of single connections compared with a simple total configuration re- 
load). 



4.3*17 Alarm events between fetch— ahead and consolidation 

Though the alarm reporting is switched— off in the I/O shelves by the restoration start message, 
there may be an event already in the queue. This alarm cannot be made persistent until end 
of the consolidation phase. Therefore it must not be acknowledged until then. But anyway it 
can be processed and also forwarded to MIB (which does not handle it until the end of consoli- 
dation). 

In CS the alarm reporting is not switched -off, but the probability of any alarms is very low. 
Anyway any eventual alarm can be handled like described above. 
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Alternatively VHM can just ignore the incoming alarms. Flow control mechanisms in FWA 
and SC resp. ensures that this alarm is repeated later. 



4.3.18 EPS switch of SC between fetch— ahead and consolidation 

If for any reason an SC or CCU performs an EPS switch between fetch— ahead and consolida- 
tion, it will lose the configuration sent in the fetch-ahead request, e.g. new connections arc 
removed as soon as the former standby SC resp. CCU is up. Because of the small probability 
of an EPS switch (note that the hold —off time is active), it can be accepted that here the connec- 
tion request is delayed until consolidation. 

If VHM receives the switch indication from an SC resp. CCU, it must keep this in mind and 
at the end of the consolidation this switch indication triggers a complete configuration reload 
of this shelf including the changes for the restoration request, handled in the consolidation. 



4.3.19 Restart of MIB between fetch- ahead and consolidation 
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A process restart of the MTB can be detected by VHM because of the broken fetch -ahead 
socket communication. Getting this trigger, VHM has to reestablish its state before the fetch- 
ahead because MIB has no persistent knowledge of the restoration request until the end of 
its consolidation phase. 

To reestablish the former state, VlIM can either perform a process restart too (quick and dirty ^ 
implementation but needs more processing time) or can perform a transaction rollback. In 
both cases it loses the fetch— ahead state indication. 

Some time after, on SC resp. CCU the consolidation time— out exceeds. Then the SC rcsp. 
ecu performs a reload out from their former database contents (SC by a warmstart, CCU 
a simple reload from its database). Note that CCU does not write the changes for fetch- ahead 
in its database while SC has two separate databases (one for the last fetch- ahead changes, 
one for the state before). After this reload, also in the I IW the pre -fetch - ahead state is rees- 
tablished (without a need for VHM to send again the complete configuration). 

4.3.20 Rejected restoration requests 

Because MIB performs no checks in the fetch -ahead, it may happen, that the fetch -ahead 
request is already performed in VHM and already present on HW but MIB rejects it during 
consolidation. In this case a reestablish of the pre-fetch-ahead state in VHM and HW is nec- 
essai^. M IB can trigger this by simply closing the fetch - ahead socket to VHM. VHM will inter- 
pret this like a MIB restart. For the following actions see 43.19. 

4.3.21 Normal request between fetch -ahead and consolidation 

This is an error case which should not happen: MIB performs no other request between fetch- 
ahead and consolidation. Anyway because of security reasons VHM should handle this case: 
When receiving a not consolidation request after fetch- ahead, VHM should reestablish its 
former state like described in 4.3.19. The incoming normal request is ignored and therefore 
repeated later by MIB. 



4.3.22 Restart of VHM between fetch -ahead and consolidation 

A restart of VHM docs not matter (of course MIB must recognize this to stop the waiting for 
the fetch-ahead response, ir^- 4. 1) because MIB will send the complete restoration request 
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during consolidation. The only thing is: VHM must not reject a consolidation without a previous 
fetch— ahead. 

Furthermore it is important that VHM sends again the RestorationStart message to trigger 
the hold - off in the shelves. Note that the SCs may have already performed a warmstart becau.sc 
of consolidation time— out. 



4.3.23 Improve handling of PM History reports 

If a fetch— ahead request arrives at VHM directly after a PM history report, the restoration ^ 
request will be delayed for the time needed to store the complete potential history data of this 
board. Though no lower order TPs arc possible in 1674LG, storing and especially transmitting 
the PM data of path and tandem connection monitors before and behind matrix needs some 
time. 

As long as this transaction is ongoing in VHM, the sockets can not be checked. Therefore this ^ 
potential delay must be accepted but note that higher priority of the fetch— ahead socket ensur- 
es that if both a PM report and a fetch— ahead request is waiting at the same time, the fetch— 
ahead request will be perfomied first. 



4.3.24 Impaicts and Caveats 

Note the following impacts: 

■ If a consolidation request contains less or other crussconnections than the former fetch— 
ahead request we get an inconsistency between MIB and VHM/hardwarc 

■ VHM sends no SNCP commands towards FWA in fetch— ahead phase 

m After having processed the fetch -ahead request the VHM internal flow control callback to 
send FW requests is disabled until a new fetch— ahead request or a consolidation request 
arrives 
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4.4 FWA 

As today FWA has to broadcast the startHoldOff message to all SCs. when it receives the Rest- "'^^ 
Start message. But in future FWA will not acknowledge the RestStart message* 

With a single message FWA receives the changes of the connectivity map for the end stage 
modules and also the changed concatenation information for all ports in the shelf. A special 
mapping procedure limits processing to this information and generates a single fetch— ahead 
container message to the active SC. This message contains only configuration changes for con- 
nectivity and concatenation. The message doesn't need a startProv/ UpdatcProv sequence. 

As a second improvement FWA shall inhibit any PM history handling for N seconds as soon 
as it receives the RestStart message at the beginn ing of the restoration . The PM history handling 
is continued when the timer expires. This is also necessary because any SC that has received 
fetch— ahead request has suspended its tasks and cannot deliver PM history data. The timer 
mustn't be restart save. 

In case FWA restarts the actual mechanism applies. VHM repeats the configuration after flow 
control time— out. As a consequence the fetch— ahead may fail and paths are not restored in 
a fast manner. 

FWA shall send the center stage configuration to the active CCU only. 

FWA docsn*t receive the syn4CS configuration message during fetch— ahead. It has to create 
a new mapping fimctton in order to calculate the TX connectivity block. 
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4.5 FW 
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The CXIOOO reload mechanism isn't suitable anymore for large matrices. The new connectivity 
is sent with a normal connection request containing only changed configuration data. The re- 
quest contains the fetch— ahead indication and FW shall start a 'consolidation supervision tim- 
er'. This timer is cleared as soon as a consolidation configuration is received. 

The fetch— ahead configuration bypasses the normal process architecure (database, hardware 
updater, etc.) to improve the performance. It is not necessary to store fetch— ahead information 
in the database — this will be done with the consolidation request. 

Only in case the fetch— ahead couldn't be closed with the corresponding consolidation pass 
(MIB or VHM crashed) the timer expires and FW shall reload the unchanged configuration 
of the database. 

In restart scenarios it may happen that a CCU receives a consolidation request without a pre- 
ceding fetch -ahead. This request must be accepted like a normal configuration request. 

FW has to distingui.sh between consolidation configuration and normal configuration reqviests. 
If the FW receives a normal request while expecting a consohdation request it shall reload 
the database into tlie ASICs before processing the request: 

Assume that the FW has received the fetch — ahead configuration and then VHM restarts and 
processes another configuration (not a consolidation). If the FW would accept this request a 
mixture of the unconfirmed / invalid fetch -ahead configuration and the normal configuration 
would be applied to the hardware and the configuration know by VHM and FW were inconsis- 
tent. 
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The FW shall also accept further fetch ahead configuratiotis before the consolidation arrivesi. 
The configuration applied to the hardware is the merged fetch— ahead data. Each fetch— ahead 
restarts the 'consohdation super/ision timer' (25scc). 

In R2 the FW shall achieve alarm detection and reporting with less than F4 value+50ms for 
primary faults (LOS, RS- AIS). 

The fetch— ahead and consolidation is done as for the CCU in RL 



4.6 SC 

Tlic following chapters give only some ideas how the SC could improve the performance* 

4.6.1 Polling 

Interfaces and Sections shall be polled with 50ms. Path monitors are also polled with a higher 
frequency but not as fast as interfaces and sections. 

4.6.2 Fetch— ahead Configuration 

During fetch- ahead FWA will only send connection related configuration with a fetch— ahead 
con tainer to the SC, therefore provisioning activity is already reduced due to the limited number 
of changed configuration blocks in the SC database. 

The fetch— ahead container implicitly contains startProv and UpdateProv and is not stored in 
the SC database. SC will implement the new connections and disables SUT generators. After- 
wards all tasks remain suspended until the consolidation request arrives. This abnormal condi- 
tion for the SC is supervised with a 'consolidation supervision timer*. 

If the timer expires before the consolidation configuration arrived the SC will execute a warm-^''^ 
start using the unchanged database content (rollback from fetch— ahead). The fetch— ahead 
configuration which w<vs configured in the ASICs is lost. Afterwards the SC is in normal opera- 
tional state. 

Between fetch -ahead and consolidation the SC shall accept further fetch — ahead configura- 
tions. The 'consolidation supervision timer' shall be restarted after each fetch -ahead request. 

If the SC receives a normal configuration request it will immediately execute a warmstart using 
the old database content. In this case the SC will not generate any answer for the configuration 
request. For further information see also chapter 4.5. 

In restart scenarios it may happen that the SC receives a consolidation request without a precc- 
dent fetch — ahead. This request must be managed like a normal configuration request. 

An estimated list of ASICs and the information that has to be partly reconfigured during Fetch 
—ahead is listed below (overview): 

• CRISTALLOS / TIEPOLO (port cards) 
new concatenation mode 

(no F3/F4, POM> TTI etc. configuration is changed) 

154 

• CRISTALLO (link boards) 
new concatenation mode 

(no F3/F4, POM, TTI etc. configuration is changed) 
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• OTIF Link boards 

No reconfiguration on OTIF link boards is necessary: Concatenation is not managed on 
OTIF and 10/11 identifier handling is suspended during hoidoff . Therefore no EPS, conse- 
quent action or connFailed reporting is active. 
Note: 

Upon reception of the 'start hold off message' SC has to disable consequent action AIS 
insertion due to 10/11— TIM. This is not impacting the fetch — ahead performance because 
VHM sends it before starting its own fetch -ahead processing, i.e. the fetch -ahead config- 
uration arrives later. 

• EVEREST (both matrix boards) 
disabling of SUT 

The new connectivity map is written to the active matrix first although this doesn't lead for 
all paths in the CI -OS matrix to an earlier connection set up. Figure 7 shows that in each I/O 
system a different a matrix copy may be active. The path from I/O X to T/O Y is only estab- 
lished if also the stand by endstage in I/O X is configured. 

Configuring the active matrix first is the best choice, e.g. i/O shelf Y only the configuration 
of the active matrix establishes the connection for a signal coming from the center stage. 
The connection on the standby matrix is not important for tliis signal direction, because the 
I/O doesn't select the stand by copy. 
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A general performance improvement could be achieved when Turc Quantify' is used to analyse ^ 
where the SC spends most of the processing time. 
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CHAPTER 5: Compatibility vith other Features 



This chapter describes how the new feature is interworking with other DXC features. 
5.1 Feature Compatibility 

• Matrix rearrangement 

In case a path cannot be routed without rearrangement it is excluded from fetch— ahead 
and consolidation. As today Ihese paths are created afterwards with normal MIB configu- 
ration requests. 

• Start hold before the restoration request 

VHM/FWAhavc to broadcast the start hold off message to all active SCs. This is done when 
the fetch— ahead request is received from MlB, SC has to disable also automatic AIS inser- 
tion due to 10/11 TIM on OTIF link boards. 
FWA will not acknowledge the RestStart message. 

• NP managemeni 

NP uses the same restoration requests as in the current systems. 

Also soft rerouting and path setup is managed with restoration requests and they're also 
split into fetch— ahead and consolidation steps. 
SNCPs used for PRC are not affected, see below, 

. SNCP 

Any SNCP will protect the traffic before the restoration manager calculates a new route. As 
a second step NP might reroute the failing path to re - establish the SNCP redundancy; This 
is not time critical and fetch- ahead/ consolidation is compatible. Protection commands 
are considered during fetch— ahead processing, 

• Soft Rerouting 

see SNCP 
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Alarm reporting 

I/O shelves which receive fetch-ahead configuration suspend their tasks and no alarm re- 
porting is dune. When the tasks arc resumed the actual alarm states are reported if they 
differ from the last reported alarm state. 

Broadcast 

iiu impact 

Center stage matrix redundancy 

no impact, also during fetch— ahead both matrix copies are configured. 

In case of SDH matrices they are symmetrically configured. For OTH matrices both copies 

get different configurations. 

OTIF link supervisi u and SC EPS 

During fetch— ahead the OTIF related configuration blocks are not sent to the SC. As a 
result newly created paths do not send 10/11 identifiers (no sent identifier configured) and 
they do not expect identifiers (number of expected identifiers is 0). The automatic conse- 
quent action AIS insertion due to 10,1 1 -TIM has to be disabled as soon as the 'StartHold- 
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Off' message i$ received. This must be done in all shelves and not only in those that later 
receive a fetch— ahead request. 

Paths which are removed are still expecting identifiers and will detect connFailed. Due to 
the hold off that was started at the beginning they will not execute consequent actions. The 
related connFailed alarm is suppressed and no SC EPS is triggered 

• Tbndem Connections 

Tandem connections are not reconfigured during fetch— ahead. If a TC source has to be 
moved to another port this might extend the down time of the path due to consequent ac- 
tions at the sink. 

No impact for the restoration performance is seen if the TCsource/sink is placed at the NP 

domain ingress/egress port. 

Note: 

A TC on an intermediate path segment is not really sensible: Any restoration which re- 
routes the segment will clear TC— PM data because the TC is disabled. 

• Ibndem Connections for SPRC 

SPRC based on TCs can only be used if they cover the complete restoration domain;, see 
Figure 8. 

In case A) SPRC and restoration are congruent and a failure will be protected in. a fast 
manner. To rc— esiablish the SPRC redundancy NP will reroute the failing working traffic 
without rcconfigurung the tandem connection, i.e. even if during fetch— ahead the TC con- 
figuration is not considered the path down time is not affected. 

In case B) SPRC and restoration domains are not congruent and a defect at the indicated 
position, outside the SPRC and inside the restoration domain would require to move the 
TC termination on the left NE to the protection port. As long as theTC is not configured the 
TC sink at the right would detect TC-UNEQ and the path is forced to AIS. 
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A) Restoration and SPRC congruent 

^ TC source has to be configured ! 




I 



^ ^j Q-^ 



I SPRC- 



-RESTORATION 



\ 

cons Action 



B) Restoration and SPRC not congruent 
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Figure 8: Fast Restoration and SPRC 



Performance monitoring / getting history data ° 
Perfomance monitoring is not reconfigured during fetch ahead. 

PM history data handhng must be suspended during restoration activities to improve per- 
formance in the NAU and because the tasks in the SC are suspended. 
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SC EPS 

If SC executes an EPS before the consolidation is finished it will loose all fetch-ahead 
configurcition and the time needed for restoration is extended for the involved paths. 
No EPS will be triggered by connection supervision because of the running hold— off, 
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MSP 

MSPsare not managed by NP but they might have been locally created at the NH — even for 
ports that are used for restoration. The NE SW layer have to consider this. 

MSSPRING 

n.a. for restoration 
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